Skip to content

cpp - Using the return value of a strcpy or related string copy function in an if statement#695

Merged
jbj merged 9 commits into
github:masterfrom
raulgarciamsft:users/raulga/c6324
Jan 10, 2019
Merged

cpp - Using the return value of a strcpy or related string copy function in an if statement#695
jbj merged 9 commits into
github:masterfrom
raulgarciamsft:users/raulga/c6324

Conversation

@raulgarciamsft

Copy link
Copy Markdown
Contributor

@raulgarciamsft raulgarciamsft requested a review from a team as a code owner December 14, 2018 23:45

@jbj jbj left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for contributing this query. I tested it on 49 projects, and it gave no results. That's a good sign since hopefully the errors found with this query are very rare.

Comment thread cpp/ql/src/Likely Bugs/Likely Typos/UsingStrcpyInConditional.ql Outdated

from IfStmt ifs,
FunctionCall func
where isStringComparisonFunction( func.getTarget().getQualifiedName() )

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In C++, when imported via #include <cstring>, these functions are named std::strcpy etc. If you use getName instead of getQualifiedName, you'll match those as well. That might also match unrelated functions like foo::bar::strcpy, but hopefully nobody names a function strcpy without ensuring it has the same behaviour as the one from the standard library.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a simple change, and hopefully it will not cause false positives, as you mentioned, it is very unlikely that somebody would name a function strcpy without it behaving similarly to the standard library. Changing it

or functionName = "_mbsncpy_l"
}

from IfStmt ifs,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why limit this to IfStmt and to particular operations in its condition? Shouldn't the warning apply at any point where the result of a string copy function is converted to a Boolean type? That would be like in #211.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added conversions to Boolean values, and also adding a dataflow to the result being used in logical/equality operations. Running a few more tests to make sure I am not missing anything.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested the query again: https://lgtm.com/query/4616339080794271386/

There are results in Microsoft CoreCLR that I presume to be false positives. I suggest using only intraprocedural data flow (DataFlow::localFlow) to avoid results like that.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. I run the same tests again with the new prototype, and I found no false positives. Thanks

and func = eop.getAChild()
)
)
select func, "Incorrect use of function " + func.getTarget().getQualifiedName() + ". Verify the logic and replace with a secure string copy function, or a string comparison function."

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We generally don't give advice in alert messages on how to remedy the problem. It's okay for an alert to be terse. I suggest

"Return value of " + func.getTarget().getQualifiedName() + " used in condition"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. I will change the string to only indicate that the return value from these functions does not reserve any value to indicate an error.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NOTE: In C++, this new approach is showing some cases twice (boolean conversion && used in a logical condition), but otherwise I miss some scenarios.
In C, it works well as there is no implicit boolean type conversion when used in logical conditions

* @kind problem
* @problem.severity error
* @precision high
* @id cpp/string-copy-function-in-if-condition

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on how we address some of my other remarks, it may be appropriate to change the id, name, description, and file name.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do

{
}

if (SomeFunction() && strcpy(szbuf1, "test")) // Bug, binary logical operator

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a test case that's one more level deep. For example, add a ! in front of strcpy here.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the last of my comments that still isn't addressed. I suggest that you change isStringCopyUsedInCondition so it doesn't require that the logical operations are contained in a condition. Don't we also want to flag code like status = !strcpy(s, "foo");?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I completely forgot about this comment during the break. Sorry about that.

@raulgarciamsft

Copy link
Copy Markdown
Contributor Author

It seems like the QHelp-Preview check failed, but I have no visibility into the failure. Please let me know what I should change.

Comment thread cpp/ql/src/Likely Bugs/Likely Typos/UsingStrcpyInConditional.qhelp Outdated
@jbj jbj added the C++ label Dec 18, 2018
@raulgarciamsft

Copy link
Copy Markdown
Contributor Author

C++ QL Tests failed (nuget failure during QL install step). I am not sure if there is anything I can do to fix it on my side.

@jbj

jbj commented Jan 3, 2019

Copy link
Copy Markdown
Contributor

Thanks. I've triggered our Jenkins-based tests instead of the broken ones, and I'll follow up tomorrow when they've completed.

@jbj

jbj commented Jan 4, 2019

Copy link
Copy Markdown
Contributor

To get rid of the duplicates, you can pick one of the messages to have precedence and suppress the other one when it's there. Change

  isStringCopyCastedAsBoolean(func, expr1, msg)
  or isStringCopyUsedInCondition(func, expr1, msg)

to

  isStringCopyCastedAsBoolean(func, expr1, msg) and
  not isStringCopyUsedInCondition(func, expr1, _)
  or
  isStringCopyUsedInCondition(func, expr1, msg)

I changed  to detect any logical operation usage (i.e. !, ==), but I kept usage in a conditional directly as a separate detection condition. I found no false positives on the projects you shared with me previously.

@jbj jbj left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests have passed, so I'll merge this.

@jbj jbj merged commit 9219214 into github:master Jan 10, 2019
@raulgarciamsft raulgarciamsft deleted the users/raulga/c6324 branch October 4, 2019 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants